Subject: Last of the Connect RIGlet changes

From: "Steve Klein (254-5623)" <[email-masked]>
Date: Tue, 18 Oct 94 17:00:54 EDT

Here is what I believe are the last of the Connect changes for
version 014.  I have added the retry absorption wording and Wayne Clark's
wording of quietly dropping unrecognized/unsupported SSP messages.

I looked back throught the wording for the states and FSM tables
and still saw remnants of the old "bringup on TEST command" stuff.
Please review the changes.

I also cleaned up the wording with respect to origin/target Data Link
Switches in the CONTACT/CONTACTED area.  We had changed the wording
to reflect the fact that a LLC2 connection could actually be started
from either the origin or target side.  Instead of having "origin or
target Data Link Switch" everywhere, I dropped the references to origin
and target Data Link Switch where the wording applied to both.  This
is consistent with the FSM tables for HALT_DL and DL_HALTED where
there is no origin/target distinction.  Please look these changes over
too.

Steve

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

2. Overview

      .
      .
      .
   As a result of this design, LLC time-outs are limited to the local LAN
   (i.e., they do not traverse the wide area).  Also, the LLC Type 2
   acknowledgments (RR's) do not traverse the WAN, thereby reducing traffic
   across the wide area links.  For SDLC links, polling and poll response
   occurs locally, not over the WAN.  Broadcast of search frames is
   controlled by the Data Link Switches once the location of a target
   system is discovered.  Finally, the switches can now apply back pressure
   to the end systems to provide flow and congestion control.

add>>  Only one copy of an LPDU is sent between Data Link Switches in SSP
add>>  messages (XIDFRAME and IFRAME).  Retries of the LPDU are absorbed by
add>>  Data Link Switch that receives it.  The Data Link Switch that transmits
add>>  the LPDU contained in an SSP message will perform retries in a manner
add>>  appropriate for the local DLC.  This may involve running a reply timer
add>>  and maintaining a poll retry count.  The length of the timer and the
add>>  number of retries is an implementation choice based on user
add>>  configuration parameters and the DLC type.

   Data Link Switching uses LAN addressing to set up connections between
   SNA systems.  SDLC attached devices are defined with MAC and SAP
   addresses to enable them to communicate with LAN attached devices.  For
   NetBIOS systems, Data Link Switching uses the NetBIOS name to forward
   datagrams and to set up connections for NetBIOS sessions.  For circuit
   establishment, SNA systems send TEST (or in some cases, XID) frames to
   the null (0x00) SAP.  NetBIOS systems have an address resolution
   procedure, based upon the Name Query and Name Recognized frames, that is
   used to establish an end-to-end circuit.
      .
      .
      .

3.5. Message Types

SCK>> Add the following paragraph to the end of section 3.5:

    A Data Link Switch should quietly drop any SSP message with a Message
    Type that is not recognized or not supported.  Receipt of such a
    message should not cause the termination of the transport connection
    to the message sender.

5.1. Data Link Switch States

      .
      .
      .

   State Name            Description
   ----------            -----------
      .
      .

   CIRCUIT_PENDING       The target DLSw is awaiting a REACH_ACK
                         response to an ICANREACH message.

SCK>> Change ICANREACH to ICANREACH_cs

      .
      .

   DISCONNECTED          The initial state with no circuit or
                         connection established, the DLSw is awaiting
                         either a CANUREACH, an ICANREACH, a
                         NETBIOS_NQ, or a NETBIOS_NR message.

SCK>> Change to:         The initial state with no circuit or
SCK>>                    connection established, the DLSw is awaiting
SCK>>                    either a CANUREACH_cs or an ICANREACH_cs.

      .
      .

   RESOLVE_PENDING       The target DLSw is awaiting either the
                         DLC_DL_STARTED indication following the
                         DLC_START_DL request (i.e., DLC is waiting
                         for a Test response as a result of sending a
                         Test command), or a NB_Name_Recognized
                         frame in response to a NB_Name_Query frame.

SCK>> Change to:         The target DLSw is awaiting the
SCK>>                    DLC_DL_STARTED indication following the
SCK>>                    DLC_START_DL request (i.e., DLC is waiting
SCK>>                    for a Test response as a result of sending a
SCK>>                    Test command).

      .
      .
      .

   The DISCONNECT state is the initial state for a new circuit.  One end
   station starts the connection via a TEST or XID command (i.e.,
   DLC_RESOLVE_C) or a NetBIOS Name Query command (not explicitly shown).
   Upon receipt, the Data Link Switches exchange a set of CANUREACH_ex,
   CANUREACH_cs, ICANREACH and REACH_ACK messages.  Upon completion of this
   four-legged exchange (note this was a "three-legged exchange" in RFC
   1434), both Data Link Switches will be in the CIRCUIT_ESTABLISHED state.
   Two pending states also exist during this exchange.  The RESOLVE_PENDING
   state is entered by the target Data Link Switch awaiting a Test response
   to a Test Command and the CIRCUIT_PENDING state is entered by the target
   DLSw awaiting the REACH_ACK reply to an ICANREACH message.

SCK>> Change to:
   The DISCONNECT state is the initial state for a new circuit.  One end
   station starts the connection an XID or SABME command (i.e.,
   DLC_RESOLVE_C or DLC_CONTACTED).  Upon receipt, the Data Link Switches
   exchange a set of CANUREACH_cs, ICANREACH_cs and REACH_ACK messages.
   Upon completion of this three-legged exchange both Data Link Switches
   will be in the CIRCUIT_ESTABLISHED state.  Three pending states also
   exist during this exchange.  The CIRCUIT_START state is entered by the
   origin Data Link Switch after is has sent the CANUREACH_cs.  The
   RESOLVE_PENDING state is entered by the target Data Link Switch awaiting
   a Test response to a Test Command and the CIRCUIT_PENDING state is entered
   by the target DLSw awaiting the REACH_ACK reply to an ICANREACH_cs message.

      .
      .
      .

5.2.1. DISCONNECTED State

      .
      .
      .

SCK>> Delete the following paragraph:
   Upon receipt of a NB_Name_Query the Data Link Switch will check the
   topology table prior to sending the NETBIOS_NQ_cs message.  If the
   target NetBIOS name is in the table, the NETBIOS_NQ_cs message will be
   sent to only those Data Link Switches that are known to be able to reach
   the given NetBIOS name.  If the NetBIOS name is not in the table, the
   NETBIOS_NQ_cs message will be sent to all known Data Link Switches.

   For SNA, the DISCONNECTED state is exited upon receipt of a CANUREACH
SCK>> Change CANUREACH to CANUREACH_cs
   message by a prospective target Data Link Switch.  In the former case,
   the Data Link Switch will issue a Test command to the target station
   (i.e., DLC_START_DL signal is presented to DLC).

      .
      .
      .

5.2.4. CIRCUIT_PENDING State

   +----------------------+---------------------+----------------------+
   |        Event         |      Action(s)      |      Next State      |
   +----------------------+---------------------+----------------------+
      .
      .
      .
   +----------------------+---------------------+----------------------+
   | DLC_XID              | Send XIDFRAME       |                      |
   +----------------------+---------------------+----------------------+
SCK>> Change to:
   +----------------------+---------------------+----------------------+
   | DLC_XID              | Drop or hold until  |                      |
   |                      | REACH_ACK received  |                      |
   +----------------------+---------------------+----------------------+
      .
      .
      .

5.2.5. CONNECT_PENDING State

      .
      .
      .

   The CONNECT_PENDING state is entered by the origin or target Data Link
   Switch when a DLC_CONTACTED signal has been received from the DLC (i.e.,
   a SABME command has been received).  A CONTACT message is then issued.
   The state is exited upon the receipt of a CONTACTED message from the
   target Data Link Switch.  If a DLC_RESET signal is received, the local
   data link is restarted and a RESTART_DL message is sent to the remote
   DLSw.

SCK>> Change to:
   The CONNECT_PENDING state is entered when a DLC_CONTACTED signal has
   been received from the DLC (i.e., a SABME command has been received).
   A CONTACT message is then issued.  The state is exited upon the receipt
   of a CONTACTED message.  If a DLC_RESET signal is received, the local
   data link is restarted and a RESTART_DL message is sent to the remote
   DLSw.

      .
      .
      .

5.2.6. CIRCUIT_ESTABLISHED State

      .
      .
      .

   The CIRCUIT_ESTABLISHED state is entered by the origin Data Link Switch
   from the DISCONNECTED state, and by the target Data Link Switch from the
   CIRCUIT_PENDING state.  The state is exited when a connection is started
   (i.e., DLC receives a SABME command) or CONTACT is received.  The next
   state is CONTACT_PENDING for the target Data Link Switch and
   CONNECT_PENDING for the either the origin Data Link Switch or the target
   Data Link Switch.

SCK>> Change to:
   The CIRCUIT_ESTABLISHED state is entered by the origin Data Link Switch
   from the CIRCUIT_START state, and by the target Data Link Switch from the
   CIRCUIT_PENDING state.  The state is exited when a connection is started
   (i.e., DLC receives a SABME command) or a CONTACT is received.  The next
   state is CONTACT_PENDING or CONNECT_PENDING.

   An ICANREACH_cs received after the transition to CONNECTED state ...
SCK>> Change to:
   An ICANREACH_cs received after the transition to CIRCUIT_ESTABLISHED state
      .
      .
      .

5.2.7. CONTACT_PENDING State

   The CONTACT_PENDING state is entered by the origin or target Data Link
   Switch upon the receipt of a CONTACT message.  This causes the Data Link
   Switch to issue a DLC_CONTACT signal to the DLC (i.e., DLC sends a SABME
   command).  This state is then exited upon the receipt of a DLC_CONTACTED
   signal from the DLC (i.e., a UA response received).

SCK>> Change to:
   The CONTACT_PENDING state is entered upon the receipt of a CONTACT message.
   This causes the Data Link Switch to issue a DLC_CONTACT signal to the DLC
   (i.e., DLC sends a SABME command).  This state is then exited upon the
   receipt of a DLC_CONTACTED signal from the DLC (i.e., a UA response
   received).

      .
      .
      .

SCK>> Add at end:
   An ICANREACH_cs received after the transition to CONTACT_PENDING state
   indicates that more than one CANUREACH_cs was sent at circuit
   establishment time and the target station was found by more than one
   Data Link Switch partner.  A HALT_DL_NOACK is sent to halt the data link
   started by the Data Link Switch partner that originated this
   ICANREACH_cs.

      .
      .
      .

5.2.8. CONNECTED State

      .
      .
      .

   The CONNECTED state is entered by the origin Data Link Switch from the
   CONNECT_PENDING state upon the receipt of a CONTACTED message.  The
   CONNECTED state is entered by the target Data Link Switch from the
   CONTACT_PENDING state upon the receipt of a DLC_CONTACTED signal.  At
   this time, the target Data Link Switch will return a CONTACTED message
   to the origin Data Link Switch.

SCK>> Change to:
   The CONNECTED state is entered from the CONNECT_PENDING state upon the
   receipt of a CONTACTED message or from the CONTACT_PENDING state upon
   the receipt of a DLC_CONTACTED signal.

      .
      .
      .

---

From: Remi Pelland <[email-masked]>
Date: Thu, 20 Oct 94 10:49:00 PDT

Steve,

In the FSM, you added the change for the DLC_XID in the CIRCUIT_PENDING 
state.  At the meeting, we realized that DLC_ERROR had the same problem. 
 Since the REACH_ACK has not been received, we can't correctly send HALT_DL 
immediately to the remote in order to take the link down.  I believe that 
the only way to handle this is to delay the HALT_DL until the REACH_ACK is 
received.

I would suggest that the following be done.  Let me know what you think.

Current FSM:

+----------------------+---------------------+----------------------+
| Receive REACH_ACK    | If Connected:       | If Connected:        |
|                      |  Send CONTACT       |   CONNECT_PENDING    |
|                      |                     | else:                |
|                      |                     |   CIRCUIT_ESTABLISHED|
+----------------------+---------------------+----------------------+

      .
      .
      .

+----------------------+---------------------+----------------------+
| DLC_ERROR            | Send HALT_DL       | DISCONNNECT_PENDING   |
+----------------------+---------------------+----------------------+

      .
      .
      .

Change to:

+----------------------+---------------------+----------------------+
| Receive REACH_ACK    | If Connected:       | If Connected:        |
|                      |  Send CONTACT       |   CONNECT_PENDING    |
|                      |                     | else If DLC_ERROR:   |
|                      |                     |   DISCONNECT_PENDING |
|                      | If DLC_Error occured| else                 |
|                      |  Send HALT_DL       |   CIRCUIT_ESTABLISHED|
+----------------------+---------------------+----------------------+

      .
      .
      .

| DLC_ERROR            |                |                      |

      .
      .
      .

Remi Pelland
Eicon Research

---

From: "Peter W. Gayek" <[email-masked]>
Date: Thu, 20 Oct 94 12:56:21 EDT

Steve,
I imbedded some very minor comments into your post, marked with PWG>.
Peter

2. Overview

      .
      .
      .

PWG> INFOFRAME not IFRAME

PWG> Change to "the LPDU received in an SSP message...", otherwise it
PWG> could be misread to mean the DLSw that sent the SSP message.

3.5. Message Types

      .
      .
      .

   State Name            Description
   ----------            -----------
      .
      .

      .
      .

      .
      .

      .
      .
      .

SCK>> Change to:

PWG> ... starts the connection via an XID ...

PWG> ... after it has sent ...

      .
      .
      .
PWG> end of my comments, so I won't repeat the rest of Steve's post

---

From: "Steve Klein (254-5623)" <[email-masked]>
Date: Fri, 21 Oct 94 07:52:39 EDT

Reference: Note from you Remi Pelland dated Thu, 20 Oct 94 10:49:00 PDT

Remi, looks good to me.  Any other comments out there?  Do we need
another substate (like Connected in this FSM table) to cover the
receipt of a DLC_ERROR while in CIRCUIT_PENDING state?

Steve

---

From: "Alan K. Bartky, Manager of Technology" <[email-masked]>
Date: Mon, 24 Oct 94 09:09:49 PDT

Steve, Remi, and Connect Working Group members.

While editing this weekend I looked at Remi's Proposed contribution
in context of the current working document.  I guess that I found
the contribution to not fit very well in the context of the state
machine.  It was confusing to follow since other state machine
diagrams deal with a single state, its events and actions.  Having
these conditionals within the state table is confusing and it seems to me
that you may need another state (or substate).

This is my opinion, If the rest of the connect group is satisfied
with the change, I can add it as is to the document as is.

Thanks,

Alan

P.S.  Are there any other contributions left from your group?  I now
have Shannon's contribution on Pacing, and would like to complete
the document as soon as your group feels that you have everything
submitted that you feel is necessary for the next DLSw document version.

--- Begin Included Message ---

Date: Fri, 21 Oct 94 07:52:39 EDT
From: "Steve Klein (254-5623)" <[email-masked]>
To: [email-masked]
Subject: RE: Last of the Connect RIGlet changes
Content-Length:       2863
Status:   

Steve

--- End Included Message ---

---

From: Remi Pelland <[email-masked]>
Date: Mon, 24 Oct 94 13:51:00 PDT

Alan,

I felt that adding a new state at this stage would be risky and confusing. 
 Furthermore, there are already conditions in today's FSMs (i.e.  "Receive 
ICANREACH_cs" in CIRCUIT_START is one example).  This is why I went with 
this aproach.

If you feel it's not too late, we can always add a new state or substate.  I 
agree that this would be cleaner and simpler.

Regards
Remi
 ----------
From: alan
To: aiw-dlsw-connect
Cc: steveklein; aiw-dlsw-coordinators
Subject: RE: Last of the Connect RIGlet changes
Date: Monday, October 24, 1994 9:09AM

Thanks,

Alan

 --- Begin Included Message ---

Steve

 --- End Included Message ---

---

From: Paul Brittain <[email-masked]>
Date: Mon, 24 Oct 94 20:25:00 BST

Alan, Steve, Remi et al,

My recollection of this point was that we said it was sufficient to assume 
general case handling of an unknown circuit ID in the form of an immediate 
HALT_DL_NOACK response.

The may not be as intellectually pure as Remi's suggestion, or Steve's 
modification of it to include a new state, but you will probably need this 
code anyway.  Why implement a separate mechanism for each case we identify?

If this feels too unclean, I can see no other issue with Remi's proposal, 
but I will still be implementing the HALT_DL_NOACK code as well to catch any 
other unexpected error cases.

Paul Brittain
Data Connection
 ----------
>Return-Path: <@networking.cary.ibm.com:[email-masked]>
>Received: from datcon.co.uk by postoffice.datcon.co.uk id
>    <[email-masked]>; Mon, 24 Oct 94 16:31:36 BST
>Received: from networking.cary.ibm.com by datcon.co.uk (4.1/SMI-4.1) id
>    AA08956; Mon, 24 Oct 94 16:36:23 GMT
>Received: from relay3.UU.NET by networking.cary.ibm.com (AIX 3.2/UCB
>    5.64/4.03) id AA11746; Mon, 24 Oct 1994 12:06:30 -0400
>Received: from uucp7.UU.NET by relay3.UU.NET with SMTP  id QQxnae18541; 
Mon,
>    24 Oct 1994 12:13:52 -0400
>Received: from synclib.UUCP by uucp7.UU.NET with UUCP/RMAIL ; Mon, 24 Oct 
1994
>    12:13:56 -0400
>Received: from alan.sync.com by synclib.sync.COM id aa01680; Mon, 24 Oct 94
>    9:11:27 PDT
>From: "Alan K. Bartky, Manager of Technology" <[email-masked]>
>To: [email-masked]
>Cc: [email-masked], [email-masked]
>Reply-To: [email-masked]
>Date: Mon, 24 Oct 94 09:09:49 PDT
>Message-Id: <[email-masked]>
>X-Mailer: SelectMAIL 1.0
>---------------------------------------------------------------------------  
 ---

---

From: "Steve Klein (254-5623)" <[email-masked]>
Date: Mon, 24 Oct 94 21:58:45 EDT

Reference: Note from Paul Brittain dated Mon, 24 Oct 94 20:25:00 BST

Paul, Remi, the problem I see with sending the HALT_DL with an
unknown circuit ID is that the origin side of the circuit will
still remain in CIRCUIT_ESTABLISHED state even though a HALT_DL_NOACK
is sent (since the HALT_DL cannot be associated with the circuit).

There is already a substate (Connected) to represent the receipt of
a SABME while in CIRCUIT_PENDING state (to account for the fact that
we don't have a circuit ID for a CONTACT yet).  We could create a
substate (like Disconnected) to keep track of the fact that we need
to send a HALT_DL when we get the origin circuit ID in the REACH_ACK.
We may want to come up with some different substate names that do not
conflict with names of circuit states.

Steve

---

From: "Alan K. Bartky, Manager of Technology" <[email-masked]>
Date: Tue, 25 Oct 94 08:24:16 PDT

Reference: Note from Steve Klein dated Mon, 24 Oct 94 21:58:45 EDT

>Steve

Whatever the outcome of the current discussion, I agree with Steve's
last comment.  It is definetly confusing to have the same names of
circuit states and substates.

I would like to go ahead and issue version 0.15 in the next couple of
days so that other issues may be discussed and so that I can start
getting feedback on the rest of the document also.  As far as getting
AP (Approved pages) status on the document, I think that this group
should make a decision on how important concluding the current discussion
is on getting AP status.  It may be necessary to issue 15, get final input
on the current discussions, and then issue a version 16 for AP status.
I will wait for the outcome of the current discussion if that is the
groups decision.

My opinion is that the State Machines should be absolutely clear and 
correct as much as possible (this is me speaking as an editor).  
Remember that this document must be clear enough for people to implement
this version without already having implemented RFC1434+ (IBM 6611
compatible) software.

Regards,

Alan

P.S. If this group could also comment on David McDonell's comments concerning
the flow diagrams and State Machine text it would be appreciated.  It is 
very valuable to get feedback from someone who has not been looking at the
document as long as we have (I know that I spend most time doing cut and paste
and it is difficult for me to get good perspective).